fix(core): Prevent volatile physical name generation #2984
Conversation
The PhysicalName generation strategy for cross-account/region use-cases could generate names that are subject to collisions/sniping when the account and region were not specified; and those names would also have changed if a stack went from re-locatable to account/region specific, even if the target environment would not have changed. The generator will now throw errors in case the account ID or region is blank or a Token.
Good point. Given that, a way to add an app-wide salt to the name generation might also be a good idea. Right now, if I deploy the same app twice, or happen to have the exact same construct tree in a second app (which is very likely, given that people are likely to call their things |
|
@rix0rrr - yeah the app-wide salt is also in my mind but I decided to NOT do it just yet because this is a little more complex (the salt would be a secret...). W/R/T the collisions - the current state of things for position-independent stacks is collision-vulnerable indeed. The update here makes the account ID and region required part of the name generation, so you couldn't get a generated name for a position-independent stack (and those use-cases typically will involve a determined account and region... because they require cross-account/region workflows). |
| let region: string | undefined = stack.region; | ||
| if (Token.isUnresolved(region)) { | ||
| region = undefined; | ||
| const region: string = stack.region; |
There was a problem hiding this comment.
Technically stack.region/account will never be undefined but that’s ok
|
Yeah I wonder how this would even go wrong. By the way, we could also make unique hard-name generation a context feature, where we generate a name on-demand and store it it context. |
|
Salts would only need to be private for buckets, btw. For other resources, since there's no global namespace there's no chance of sniping, we'd only need unique values. But yes, to protect against sniping we'd need unique AND secret values. |
Follow up on #2984, which introduced a bunch of new account numbers that we need to whitelist.
The PhysicalName generation strategy for cross-account/region use-cases could generate names that are subject to collisions/sniping when the account and region were not specified; and those names would also have changed if a stack went from re-locatable to account/region specific, even if the target environment would not have changed. The generator will now throw errors in case the account ID or region is blank or a Token.
Follow up on aws#2984, which introduced a bunch of new account numbers that we need to whitelist.
The PhysicalName generation strategy for cross-account/region use-cases
could generate names that are subject to collisions/sniping when the
account and region were not specified; and those names would also have
changed if a stack went from re-locatable to account/region specific,
even if the target environment would not have changed.
The generator will now throw errors in case the account ID or region is
blank or a Token.
Pull Request Checklist
designfolderBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.